Direct Network Access by a Memory Mapped Peripheral Device for Scheduled Data Transfer on the Network

ABSTRACT

A network interface peripheral device (NIP) may include a network interface for communicating with a network, and an interconnect interface for communicating with a processor subsystem. Peripheral data buffers (PDBs) in the NIP may hold data received from and/or distributed to peer peripherals by the NIP, and network data buffers (NDBs) may hold payload data of scheduled data streams transmitted to and/or received from the network by the NIP. A data handler in the NIP may generate the payload data from the data in the PDBs, and store the payload data in the NDBs according to scheduled data handler transmit events. The data handler may obtain the data from the payload data in the NDBs and store the obtained data in the PDBs according to scheduled data handler receive events. The NIP may include a mirrored finite state machine operating at the device level (of a device that may include the NIP) and controlled by a centralized system configuration entity to manage configuration of the NIP and coordinate the internal configuration of the NIP with a network configuration flow.

FIELD OF THE INVENTION

The present invention relates to the field of distributed systems, andmore particularly to direct network access by peripheral devices forscheduled data transfers on the network.

DESCRIPTION OF THE RELATED ART

In many industrial applications (and others), instruments collect dataor information from an environment or unit under test (UUT), and mayalso analyze and process acquired data. Some instruments provide teststimuli to a UUT. Examples of instruments include oscilloscopes, digitalmultimeters, pressure sensors, arbitrary waveform generators, digitalwaveform generators, etc. The information that may be collected byrespective instruments includes information describing voltage,resistance, distance, velocity, pressure, oscillation frequency,humidity, and/or temperature, among others. Computer-basedinstrumentation systems typically include transducers for capturing aphysical phenomenon and generating a representative electrical signal,signal conditioning logic to perform amplification on the electricalsignal, isolation, and/or filtering, and analog-to-digital (A/D)conversion logic for receiving analog signals and providingcorresponding digital signals to the host computer system.

In a computer-based system, the instrumentation hardware or device istypically an expansion board plugged into one of the I/O slots of thecomputer system. In another common instrumentation system configuration,the instrumentation hardware is coupled to the computer system via othermeans such as through a VXI (VME extensions for Instrumentation) bus, aGPIB (General Purpose Interface Bus), a PXI (PCI extensions forInstrumentation) bus, Ethernet, a serial port or bus, or parallel portof the computer system. The instrumentation hardware may include a DAQ(Data Acquisition) board, a computer-based instrument such as amultimeter, or another type of instrumentation device. In another commonsystem configuration, a chassis and boards inserted in the chassis mayoperate as a standalone instrument or instrument suite, although in somecases a host computer may be used to configure or program the boardsprior to, or during operation. The instrumentation hardware may beconfigured and controlled by software executing on a host computersystem coupled to the system, or by a controller card installed in thechassis. The software for configuring and controlling theinstrumentation system typically includes driver software and theinstrumentation application software, or the application.

A host computer system is typically a processor-based device whichfundamentally consists of a Central Processing Unit (CPU), memory andperipherals. A processor architecture or processor subsystem maytypically use a memory-mapped interconnect to connect peripherals to thememory. A memory bus generally acts as an interface to the CPU, thememory, and the memory interconnect. To enable data exchange between theperipherals and the CPU, a memory-mapped interconnect, like PCI-Expressfor example, is used to connect the peripherals to the memory bus. Toexchange data between the CPU and the peripherals, data is written toand read from the shared memory. Memory mapped interconnects also allowpeer-to-peer data exchange between the peripherals, bypassing the memorybus and the memory.

To connect such a processor-based system to a network (e.g. Ethernet),one of the peripherals implements the network interface. Data from thememory or any of the peer-peripherals can be transmitted to and receivedfrom the network via the network interface inside the network interfaceperipheral. Data from the network interface peripheral can be written tothe memory or read from the memory via a first data path, for the CPU toexchange data with other devices on the network. Additionally peerperipherals other than the network interface peripheral can alsoexchange data with the network via a second data path, bypassing thememory bus and the CPU. Converged networking technologies (e.g. IEEE802.1Q with time-sensitive networking features) enable best-effort andscheduled traffic (latency critical) to coexist on the same network.While such a system provides a solid and effective interconnect betweenthe various distributed elements, including various devices/elementsthat are also part of or connected to the network, there is room forimprovement in the design of the peripherals to allow direct networkaccess for scheduled data transfers on the network.

Other corresponding issues related to the prior art will become apparentto one skilled in the art after comparing such prior art with thepresent invention as described herein.

SUMMARY

Various embodiments of a system and method for direct network access bya memory mapped peripheral device for scheduled data transfer on thenetwork are presented below.

A broad range of applications are currently driving the need fordistributed data acquisition and control. Examples of such applicationsinclude infotainment, industrial control, power transmission and/orgeneration, transportation control, automotive control, avionics, homenetworks, media converters, machine/structural health monitoring, andreal-time testing, just to name a few. Such applications require thesame level of synchronization over a network as achieved inside achassis. Timely transfer of data from sensors to processing units isbecoming increasingly important for “closing the loop” over the network,efficient bandwidth utilization of the network, and reducing cycle time(increasing productivity).

Converged networking technologies (e.g. IEEE 802.1Q with time-sensitivenetworking features) enable best-effort and scheduled traffic (latencycritical) to coexist on the same network. Various mechanisms inexistence today enable implementation of network functions onperipherals to transmit and receive packets of data on the network frommemory (CPU access) using a schedule and with minimal jitter. However,there are presently no mechanisms defined for peer peripherals totransmit and receive data on a network via a peripheral implementing thenetwork interface and using a schedule. Various embodiments arepresented herein of a system and method for implementing direct networkaccess by a memory mapped peripheral device for scheduled data transferson the network.

Accordingly, a network interface peripheral device may include a networkinterface for communicating with a network, and may also include aninterconnect interface for communicating with a processor subsystem. Thenetwork interface peripheral device may further include a first set ofbuffers to hold peripherals data associated with peer peripheral devicescoupled to the processor subsystem, and a second set of buffers to holdpayload data of scheduled data streams transmitted over the network. Thenetwork interface peripheral device may use a data handler to generatethe payload data from the peripherals data and store the payload data inthe second set of buffers for transmission over the network, accordingto one or more timed events, and/or may further use the data handler togenerate the peripherals data from the payload data and store theperipherals data in the second set of buffers for transmission to thepeer peripheral devices, according to the one or more timed events. Ascheduler in the network interface peripheral device, may create the oneor more timed events, which may include one or more transmit events,with each respective transmit event instructing the data handler tofetch corresponding transmit data included in the peripherals data,generate at least a portion of the payload data from the correspondingtransmit data, and store the portion of the payload data in the secondset of buffers for transmission over the network. The one or more timedevents may also include one or more receive events, with each respectivereceive event instructing the data handler to fetch correspondingreceive data included in the payload data, generate at least a portionof the peripherals data from the corresponding receive data, and storethe portion of the peripherals data in the first set of buffers fortransmission to the peer peripheral devices.

In some embodiments, the peripherals data may include one or more datasets, with the first set of buffers including one respective buffer perpeer peripheral device per data set. The peripherals data may includemultiple data sets corresponding to a single peer peripheral device. Thesecond set of buffers may include one respective buffer per scheduleddata stream, and each scheduled data stream may include transmit datastreams transmitted by the network interface peripheral device and/orreceive data streams received by the network interface peripheraldevice. In some embodiments, the data handler may multiplex peripheralsdata from multiple buffers of the first set of buffers into a singlebuffer of the second set of buffers. The data handler may distributepayload data from a single buffer of the second set of buffers intomultiple buffers of the first set of buffers. In addition, the datahandler may transmit data over the interconnect interface to the peerperipheral devices from the first set of buffers, and/or may receivedata over the interconnect interface from the peer peripheral devicesinto the first set of buffers.

In some embodiments, the network interface peripheral device may furtherinclude a state machine to coordinate internal initialization and set upof the peripheral device with a centralized system configuration flow,and the state machine may be controlled by a centralized systemconfiguration entity disposed outside of the peripheral device.Furthermore, the network interface peripheral device may be part of amain host device that also includes the processor subsystem and the peerperipheral devices, and the main host device may be included in anetworked system that also includes the centralized system configurationentity along with a network schedule generator and an applicationschedule generator.

In some embodiments, the network interface peripheral device may be setup for operation as follows. When the network interface peripheraldevice is powered on, it may boot up into an Initialization state, andan application executing on the main host device (e.g. in the processorsubsystem) may receive a request from the centralized systemconfiguration entity to transition the network interface peripheraldevice to a Configuration state. Upon receiving that request, theapplication may perform internal application initialization which mayinclude configuring the data sources and data sinks between theprocessor subsystem and the peripheral devices, and between the variousperipheral devices themselves. The internal application initializationmay also include configuring the network interface peripheral devicewith the first set of buffers to store the data sets from the peerperipheral devices. The application may then configure the data handlerwith the source and sink information of the first set of buffers, e.g.with link information between the first set of buffers and data sets onthe peer peripheral devices. The network interface peripheral device maythen create the mapping between the first set of buffers and the secondset of buffers, e.g. based on the number of network streams and payloadsize.

The application may then publish the requirements for systemconfiguration, e.g. the number of network streams it intends totransmit/receive, and may also publish the application timingconstraints (e.g. fastest period it can run the application, minimumpreparation time before performing any function, etc.) for the systemconfiguration to read. At this point, the application may be ready toreceive configuration information from the centralized systemconfiguration entity. After this internal initialization, theapplication may transition the main host device into a Configurationstate.

The network schedule generator schedule the network streams between thedevices connected to each other over the network (including the mainhost device and any additional devices). The application schedulegenerator may compute the schedule of timed functions on the masterdevice. The centralized system configuration entity may read thepublished stream and application timing information, and may obtain theuser requirements—e.g. period of streams, stream link information,latency requirements etc.—and provide these user requirements along withthe stream and application timing constraints to the applicationschedule generator. The application schedule generator may compute thestream relationships (e.g. does one stream need to finish before thesecond one starts, etc.) and possible start times for the streams andthe maximum latency acceptable to meet the application timingconstrains. This information may then be relayed to the network schedulegenerator which may compute the schedule for the streams within thenetwork. It may return the start time of streams for transmission andthe expected arrival time of the streams for reception to the systemconfiguration entity. The system configuration may distribute thisinformation along with application timing information to all the devicesit is configuring, and request all the devices to transition to a Readystate.

Receipt of a state transition request by the main host device totransition to the Ready state is indicative of the application havingreceived the stream schedule and application timing information.Accordingly, the main host device may provide the stream schedule to thenetwork interface peripheral device, which may then configure thenetwork transmission and reception layer with this schedule, and link itto the second set of buffers. The network interface peripheral devicemay also configures the scheduler with timing information indicative of(or indicating) when to create the timed events (e.g. data handlertransmit events and data handler receive events. These events instructthe data handler to move the data between the first set of buffers andthe peer peripheral devices, and between the first set of buffers andthe second set of buffers.

This Summary is intended to provide a brief overview of some of thesubject matter described in this document. Accordingly, it will beappreciated that the above-described features are merely examples andshould not be construed to narrow the scope or spirit of the subjectmatter described herein in any way. Other features, aspects, andadvantages of the subject matter described herein will become apparentfrom the following Detailed Description, Figures, and Claims.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 shows an exemplary circuit-block diagram of a processor-baseddevice that includes multiple peripheral devices, one of which is animproved network interface peripheral device capable of facilitatingscheduled data transfer over the network, according to some embodiments;

FIG. 2 shows an exemplary circuit-block diagram of an improved networkinterface peripheral device with network function capable of managingscheduled data transfer over the network, according to some embodiments;

FIG. 3 shows an exemplary block diagram of the finite state machine fromFIG. 2, according to some embodiments;

FIG. 4 shows an exemplary system diagram of a system configuration withan improved peripheral device, according to some embodiments;

FIG. 5 shows an exemplary timing diagram illustrating the timing of adata handler transmit event, according to some embodiments;

FIG. 6 shows an exemplary flow chart illustrating configuration of anetwork interface peripheral device that manages scheduled data transferover the network, according to some embodiments;

FIG. 7A illustrates an exemplary instrumentation control systemaccording to some embodiments;

FIG. 7B illustrates an exemplary industrial automation system accordingto some embodiments;

FIG. 8A is a high level block diagram of an exemplary system which mayexecute or utilize graphical programs, according to some embodiments;

FIG. 8B illustrates an exemplary system which may perform control and/orsimulation functions utilizing graphical programs, according to someembodiments; and

FIG. 9 is an exemplary block diagram of the computer systems of FIGS.7A, 7B, and 8B, according to some embodiments.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are herein described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

The following is a glossary of terms used in the present application:

Memory Medium—Any of various types of non-transitory computer accessiblememory devices or storage devices. The term “memory medium” is intendedto include an installation medium, e.g., a CD-ROM, floppy disks 104, ortape device; a computer system memory or random access memory such asDRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; a non-volatile memorysuch as a Flash, magnetic media, e.g., a hard drive, or optical storage;registers, or other similar types of memory elements, etc. The memorymedium may comprise other types of non-transitory memory as well orcombinations thereof. In addition, the memory medium may be located in afirst computer in which the programs are executed, or may be located ina second different computer which connects to the first computer over anetwork, such as the Internet. In the latter instance, the secondcomputer may provide program instructions to the first computer forexecution. The term “memory medium” may include two or more memorymediums which may reside in different locations, e.g., in differentcomputers that are connected over a network.

Carrier Medium—a memory medium as described above, as well as a physicaltransmission medium, such as a bus, network, and/or other physicaltransmission medium that conveys signals such as electrical,electromagnetic, or digital signals.

Programmable Hardware Element—includes various hardware devicescomprising multiple programmable function blocks connected via aprogrammable interconnect. Examples include FPGAs (Field ProgrammableGate Arrays), PLDs (Programmable Logic Devices), FPOAs (FieldProgrammable Object Arrays), and CPLDs (Complex PLDs). The programmablefunction blocks may range from fine grained (combinatorial logic or lookup tables) to coarse grained (arithmetic logic units or processorcores). A programmable hardware element may also be referred to as“reconfigurable logic”.

Software Program—the term “software program” is intended to have thefull breadth of its ordinary meaning, and includes any type of programinstructions, code, script and/or data, or combinations thereof, thatmay be stored in a memory medium and executed by a processor. Exemplarysoftware programs include programs written in text-based programminglanguages, such as C, C++, PASCAL, FORTRAN, COBOL, JAVA, assemblylanguage, etc.; graphical programs (programs written in graphicalprogramming languages); assembly language programs; programs that havebeen compiled to machine language; scripts; and other types ofexecutable software. A software program may comprise two or moresoftware programs that interoperate in some manner. Note that variousembodiments described herein may be implemented by a computer orsoftware program. A software program may be stored as programinstructions on a memory medium.

Hardware Configuration Program—a program, e.g., a netlist or bit file,that can be used to program or configure a programmable hardwareelement.

Program—the term “program” is intended to have the full breadth of itsordinary meaning. The term “program” includes 1) a software programwhich may be stored in a memory and is executable by a processor or 2) ahardware configuration program useable for configuring a programmablehardware element.

Graphical Program—A program comprising a plurality of interconnectednodes or icons, wherein the plurality of interconnected nodes or iconsvisually indicate functionality of the program. The interconnected nodesor icons are graphical source code for the program. Graphical functionnodes may also be referred to as blocks.

The following provides examples of various aspects of graphicalprograms. The following examples and discussion are not intended tolimit the above definition of graphical program, but rather provideexamples of what the term “graphical program” encompasses:

The nodes in a graphical program may be connected in one or more of adata flow, control flow, and/or execution flow format. The nodes mayalso be connected in a “signal flow” format, which is a subset of dataflow.

Exemplary graphical program development environments which may be usedto create graphical programs include LabVIEW®, DasyLab™, DIADem™ andMatrixx/SystemBuild™ from National Instruments, Simulink® from theMathWorks, VEE™ from Agilent, WiT™ from Coreco, Vision Program Manager™from PPT Vision, SoftWIRE™ from Measurement Computing, Sanscript™ fromNorthwoods Software, Khoros™ from Khoral Research, SnapMaster™ from HEMData, VisSim™ from Visual Solutions, ObjectBench™ by SES (Scientific andEngineering Software), and VisiDAQ™ from Advantech, among others.

The term “graphical program” includes models or block diagrams createdin graphical modeling environments, wherein the model or block diagramcomprises interconnected blocks (i.e., nodes) or icons that visuallyindicate operation of the model or block diagram; exemplary graphicalmodeling environments include Simulink®, SystemBuild™, VisSim™,Hypersignal Block Diagram™, etc.

A graphical program may be represented in the memory of the computersystem as data structures and/or program instructions. The graphicalprogram, e.g., these data structures and/or program instructions, may becompiled or interpreted to produce machine language that accomplishesthe desired method or process as shown in the graphical program.

Input data to a graphical program may be received from any of varioussources, such as from a device, unit under test, a process beingmeasured or controlled, another computer program, a database, or from afile. Also, a user may input data to a graphical program or virtualinstrument using a graphical user interface, e.g., a front panel.

A graphical program may optionally have a GUI associated with thegraphical program. In this case, the plurality of interconnected blocksor nodes are often referred to as the block diagram portion of thegraphical program.

Node—In the context of a graphical program, an element that may beincluded in a graphical program. The graphical program nodes (or simplynodes) in a graphical program may also be referred to as blocks. A nodemay have an associated icon that represents the node in the graphicalprogram, as well as underlying code and/or data that implementsfunctionality of the node. Exemplary nodes (or blocks) include functionnodes, sub-program nodes, terminal nodes, structure nodes, etc. Nodesmay be connected together in a graphical program by connection icons orwires.

Data Flow Program—A Software Program in which the program architectureis that of a directed graph specifying the flow of data through theprogram, and thus functions execute whenever the necessary input dataare available. Said another way, data flow programs execute according toa data flow model of computation under which program functions arescheduled for execution in response to their necessary input databecoming available. Data flow programs can be contrasted with proceduralprograms, which specify an execution flow of computations to beperformed. As used herein “data flow” or “data flow programs” refer to“dynamically-scheduled data flow” and/or “statically-defined data flow”.

Graphical Data Flow Program (or Graphical Data Flow Diagram)—A GraphicalProgram which is also a Data Flow Program. A Graphical Data Flow Programcomprises a plurality of interconnected nodes (blocks), wherein at leasta subset of the connections among the nodes visually indicate that dataproduced by one node is used by another node. A LabVIEW VI is oneexample of a graphical data flow program. A Simulink block diagram isanother example of a graphical data flow program.

Graphical User Interface—this term is intended to have the full breadthof its ordinary meaning. The term “Graphical User Interface” is oftenabbreviated to “GUI”. A GUI may comprise only one or more input GUIelements, only one or more output GUI elements, or both input and outputGUI elements.

The following provides examples of various aspects of GUIs. Thefollowing examples and discussion are not intended to limit the ordinarymeaning of GUI, but rather provide examples of what the term “graphicaluser interface” encompasses:

A GUI may comprise a single window having one or more GUI Elements, ormay comprise a plurality of individual GUI Elements (or individualwindows each having one or more GUI Elements), wherein the individualGUI Elements or windows may optionally be tiled together.

A GUI may be associated with a graphical program. In this instance,various mechanisms may be used to connect GUI Elements in the GUI withnodes in the graphical program. For example, when Input Controls andOutput Indicators are created in the GUI, corresponding nodes (e.g.,terminals) may be automatically created in the graphical program orblock diagram. Alternatively, the user can place terminal nodes in theblock diagram which may cause the display of corresponding GUI Elementsfront panel objects in the GUI, either at edit time or later at runtime. As another example, the GUI may comprise GUI Elements embedded inthe block diagram portion of the graphical program.

Front Panel—A Graphical User Interface that includes input controls andoutput indicators, and which enables a user to interactively control ormanipulate the input being provided to a program, and view output of theprogram, while the program is executing.

A front panel is a type of GUI. A front panel may be associated with agraphical program as described above.

In an instrumentation application, the front panel can be analogized tothe front panel of an instrument. In an industrial automationapplication the front panel can be analogized to the HMI (Human MachineInterface) of a device. The user may adjust the controls on the frontpanel to affect the input and view the output on the respectiveindicators.

Graphical User Interface Element—an element of a graphical userinterface, such as for providing input or displaying output. Exemplarygraphical user interface elements comprise input controls and outputindicators.

Input Control—a graphical user interface element for providing userinput to a program. An input control displays the value input by theuser and is capable of being manipulated at the discretion of the user.Exemplary input controls comprise dials, knobs, sliders, input textboxes, etc.

Output Indicator—a graphical user interface element for displayingoutput from a program. Exemplary output indicators include charts,graphs, gauges, output text boxes, numeric displays, etc. An outputindicator is sometimes referred to as an “output control”.

Computer System—any of various types of computing or processing systems,including a personal computer system (PC), mainframe computer system,workstation, network appliance, Internet appliance, personal digitalassistant (PDA), television system, grid computing system, or otherdevice or combinations of devices. In general, the term “computersystem” can be broadly defined to encompass any device (or combinationof devices) having at least one processor that executes instructionsfrom a memory medium.

Measurement Device—includes instruments, data acquisition devices, smartsensors, and any of various types of devices that are configured toacquire and/or store data. A measurement device may also optionally befurther configured to analyze or process the acquired or stored data.Examples of a measurement device include an instrument, such as atraditional stand-alone “box” instrument, a computer-based instrument(instrument on a card) or external instrument, a data acquisition card,a device external to a computer that operates similarly to a dataacquisition card, a smart sensor, one or more DAQ or measurement cardsor modules in a chassis, an image acquisition device, such as an imageacquisition (or machine vision) card (also called a video capture board)or smart camera, a motion control device, a robot having machine vision,and other similar types of devices. Exemplary “stand-alone” instrumentsinclude oscilloscopes, multimeters, signal analyzers, arbitrary waveformgenerators, spectroscopes, and similar measurement, test, or automationinstruments.

A measurement device may be further configured to perform controlfunctions, e.g., in response to analysis of the acquired or stored data.For example, the measurement device may send a control signal to anexternal system, such as a motion control system or to a sensor, inresponse to particular data. A measurement device may also be configuredto perform automation functions, i.e., may receive and analyze data, andissue automation control signals in response.

Functional Unit (or Processing Element)—refers to various elements orcombinations of elements. Processing elements include, for example,circuits such as an ASIC (Application Specific Integrated Circuit),portions or circuits of individual processor cores, entire processorcores, individual processors, programmable hardware devices such as afield programmable gate array (FPGA), and/or larger portions of systemsthat include multiple processors, as well as any combinations thereof.

Automatically—refers to an action or operation performed by a computersystem (e.g., software executed by the computer system) or device (e.g.,circuitry, programmable hardware elements, ASICs, etc.), without userinput directly specifying or performing the action or operation. Thusthe term “automatically” is in contrast to an operation being manuallyperformed or specified by the user, where the user provides input todirectly perform the operation. An automatic procedure may be initiatedby input provided by the user, but the subsequent actions that areperformed “automatically” are not specified by the user, i.e., are notperformed “manually”, where the user specifies each action to perform.For example, a user filling out an electronic form by selecting eachfield and providing input specifying information (e.g., by typinginformation, selecting check boxes, radio selections, etc.) is fillingout the form manually, even though the computer system must update theform in response to the user actions. The form may be automaticallyfilled out by the computer system where the computer system (e.g.,software executing on the computer system) analyzes the fields of theform and fills in the form without any user input specifying the answersto the fields. As indicated above, the user may invoke the automaticfilling of the form, but is not involved in the actual filling of theform (e.g., the user is not manually specifying answers to fields butrather they are being automatically completed). The presentspecification provides various examples of operations beingautomatically performed in response to actions the user has taken.

Concurrent—refers to parallel execution or performance, where tasks,processes, or programs are performed in an at least partiallyoverlapping manner. For example, concurrency may be implemented using“strong” or strict parallelism, where tasks are performed (at leastpartially) in parallel on respective computational elements, or using“weak parallelism”, where the tasks are performed in an interleavedmanner, e.g., by time multiplexing of execution threads.

Wireless—refers to a communications, monitoring, or control system inwhich electromagnetic or acoustic waves carry a signal through spacerather than along a wire.

Approximately—refers to a value being within some specified tolerance oracceptable margin of error or uncertainty of a target value, where thespecific tolerance or margin is generally dependent on the application.Thus, for example, in various applications or embodiments, the termapproximately may mean: within 0.1% of the target value, within 0.2% ofthe target value, within 0.5% of the target value, within 1%, 2%, 5%, or10% of the target value, and so forth, as required by the particularapplication of the present techniques.

Optimization—refers to the technical process of determining or selectinga best or improved element or configuration from a set of availablealternatives with regard to some specified criteria (e.g., an objectivefunction, and possibly constraints), and generally within some specifiedtolerance. Note that in practical use, an optimized system (or process)is improved (with respect to specified criteria), but may or may not bethe absolute best or ideal solution. Said another way, optimizationoperates to improve a system or process, and may approach themathematically optimum solution to within some tolerance, which may bedependent on the application, e.g., within 1%, 2%, 5%, 10%, etc., of themathematically optimal solution. Thus, as used herein, the terms“optimized”, “optimum”, and “optimal” mean “improved with respect tospecified criteria”.

Global Optimization—refers to a type of optimization in which a systemor process with interdependent components or sub-processes is improvedby varying multiple parameters or aspects of the system or process atthe same time, generally with non-linear results. Note that ideal globaloptimization (finding the mathematically globally optimum solution) isgenerally intractable, because in even moderately complex systems andprocesses there are many more possible configurations and resultingbehaviors than can be searched or considered in a reasonable amount oftime. Thus, practically, global optimization operates to improve acomplex system or process by varying multiple parameters concurrently,and may approach the mathematically globally optimum solution to withinsome tolerance, which may be dependent on the application, e.g., within1%, 2%, 5%, 10%, etc., of the mathematically globally optimal solution.Thus, as used herein, the terms “globally optimized”, “globallyoptimum”, and “globally optimal” mean “globally improved with respect tospecified criteria”. One example of a global optimization method isdifferential evolution, which optimizes a problem (system or process)via iterative improvement of candidate solutions with respect to somespecified measure of quality.

Latency Requirements—refers to the latency (time/duration) desired by asystem application for a stream regarding the time from transmissionfrom the master device producing the stream to the time when it isreceived by a master device consuming the stream.

Period—refers to the cyclic rate at which the stream is transmitted,i.e., the duration of one cycle.

Timed Function Characterization—refers to the determination of the worstcase execution time (WCET), and the minimum and maximum period forexecution of the timed function.

Time Sensitive Stream Bandwidth—refers to the data transmitted everycycle in a stream.

Time Sensitive Stream Characterization—refers to the (transmission) txcopy time and (reception) rx copy time by a stream on a master device.

Path Computation—refers to an algorithm to compute optimal routing of astream from a master device producing the stream to a master deviceconsuming the stream.

Performance Metrics of the Network—refers to delays (i.e., latencies)encountered by a stream as it passes through a bridge/switch andpropagation (e.g., cable) delay.

Link Speed—refers to network bandwidth available for transmission of astream (e.g., 1 Gigabit/sec, 10 Gigabit/sec, and so forth).

Network Topology—refers to or specifies the connectivity of componentsof a network, e.g., the bridges/switches connecting one master device toanother.

Physical I/O—refers to input and output signals formonitoring/controlling a physical system, process, or environment. Forexample, one exemplary physical input is a physical signal derived froma sensor or a motor drive indicating the present condition of theenvironment or system connected to the sensor or motor drive. Similarly,one exemplary physical output is a physical signal used to change thestate of an actuator or a motor drive with the intention of causing achange to the environment or system connected to the actuator or motordrive.

Centralized Configuration Device—refers to a configuration device in adistributed system, i.e., in a networked system, that operates toconfigure other devices in the system, where the configuration device'sfunctionality is not distributed, but rather is comprised within asingle device or entity. In other words, the configuration deviceprovides for centralized configuration functionality in an otherwisedistributed system.

Processor-Based Device (or System) with Peripherals

FIG. 1 shows an exemplary circuit-block diagram of a processor-baseddevice (or system) 100 that includes multiple peripheral devices, one ofwhich is an improved network interface peripheral device capable offacilitating scheduled data transfer over the network. As shown in FIG.1, the processor architecture or processor subsystem 102 uses amemory-mapped interconnect 108 to connect peripherals 112, 114 . . . 116to the memory 110. A memory bus 106 acts as an interface to the CPU 104,the memory 110 and the memory interconnect 108. To enable data exchangebetween the peripherals 112, 114 . . . 116 and CPU 104, a memory-mappedinterconnect 108 (e.g. PCI-Express) is used connect the peripherals 112,114 . . . 116 to memory bus 106. To exchange data between CPU 104 andperipherals 112, 114 . . . 116, data is written to and read from theshared memory 110. Memory mapped interconnects also allow peer-to-peerdata exchange between peripherals 112, 114 . . . 116, bypassing thememory bus 106 and memory 110.

One of the peripherals, in this case peripheral device 112, mayimplement a network interface (or network interface function) to connectprocessor-based system 102 to a network (e.g. to the Ethernet,exemplified as Local Area Network, or LAN 118 in FIG. 1). Data frommemory 110 or peer-peripherals 112, 114 . . . 116 may be transmitted toand received from network 118 via network interface 120 through networkinterface peripheral device 112. Data from peripheral device 112 may bewritten to memory 110 or read from memory 110 via data path 2,facilitating data exchange between CPU 104 and other devices on network118. Additionally, peer-peripheral devices, such as peripheral 114(“peer-peripherals” and “peer-peripheral devices” referring toperipherals other than the peripheral device—e.g. 112—implementing thenetwork function) may also exchange data with network 118 via data path1, bypassing memory bus 106 and CPU 104. Converged networkingtechnologies (e.g. IEEE 802.1Q with time-sensitive networking features)enable best-effort and scheduled traffic (latency critical) to coexiston the same network. Accordingly, peripheral device 112 also facilitatesdirect network access by device/system 100 for scheduled data transferson LAN 118.

Improved Peripheral Device

To enable or facilitate scheduled data transfers on the network directlyfrom peripherals, such as the peripheral devices shown in FIG. 1, forexample, certain enhancements may be implemented in the design ofperipherals/peripheral devices. The enhancements may be additions to aperipheral device that implements/performs a network interface function,such as peripheral device 112 in FIG. 1. One exemplary improvedperipheral device 200—according to some embodiments—is shown in FIG. 2.Peripheral device 112 shown in FIG. 1 may be an instance of a peripheraldevice such as peripheral device 200. Other peripherals (which areproducing/consuming data, e.g. peripheral devices 114 . . . 116 shown inFIG. 1) in a system that includes at least one improved peripheraldevice (as disclosed herein) may not require any changes. Accordingly,one or more functions may be added to the improved peripheral device, aswill be further discussed below. It should also be noted, with regardsto peripheral device 200, that various currently existing embodiments ofMemory Mapped Interconnect Interface 212 and NetworkTransmission/Reception Layer Interface 208 may be included and used inperipheral device 200.

Overall, various components and/or functions may be included in aperipheral device to enable the peripheral device to implement a networkinterface capable of transmitting and receiving data on the network,using a schedule. Peripheral device 200 may therefore include PeripheralData Buffers (PDBs) 220. Buffers 220 may temporarily hold data that isreceived from peer peripheral devices (for copying into schedulednetwork streams that are to be transmitted onto the network) or datathat is to be sent to peer peripheral devices (which are copied out ofscheduled streams received from the network). In reference to a systemsimilar to system 100, by way of example, the improved peripheral device200 may be represented by peripheral device 112, and peer peripheraldevices may be represented by peripheral devices 114 . . . 116.Peripheral device 200 may include one buffer per peer peripheral deviceper data set that is to be transmitted or received on a schedule. A peerperipheral may implement multiple data sets.

Peripheral device 200 may further include Network Data Buffers (NDBs)222. Buffers 222 may hold the payload data of scheduled streams that aretransmitted on the network or payload data of scheduled streams receivedfrom the network. There may be a buffer for each transmitted or receivednetwork stream. Data from multiple PDBs may be multiplexed into one NDBfor transmission. Data received from a scheduled stream in one NDB maybe distributed into multiple PDBs. The network transmission/receptionlayer 208 may be configured to transmit network streams using thepayload data in the NDBs based on the schedule for each stream, and copydata into the NDBs upon receiving scheduled streams from the network.

Peripheral device 200 may also include a Data Handler Function (DHF)210. The data handler function 210 may handle collecting data frommultiple PDBs, and may copy them into an NDB (e.g. in a pre-specifiedorder) for transmission onto the network. DHF 210 may also handledistributing data from one NDB into one or more PDBs upon reception ofscheduled data from the network. DHF 210 may also facilitate themovement of data—received from the network—from the PDBs to the peerperipherals, using the memory mapped interconnect interface 212. DHF 210may fetch data from the other peripheral devices (that have beenconfigured to send data) before transmission is scheduled to occur onthe network, through the memory mapped interconnect interface 212.

Peripheral device 200 may include a Scheduling Function (SF) 204 whichmay create a Data Handler (DH) transmit event before transmission of astream to instruct the DHF 210 to fetch data from the other peripheraldevices (e.g. from each of the other peripheral devices) and create thepayload for the stream. The SF 204 may also create a DH receive event onreception of stream data (into an NDB) to instruct the DHF 210 todistribute the stream payload into one or more PDBs and send each dataset (from a corresponding PDB) to the respective peripheral consumingthe data set.

Peripheral device 200 may also include a state machine (SM) 206, oneexample of which—according to some embodiments—is shown in FIG. 3. SM206 may function at the device level and may be controlled by acentralized system configuration entity that manages configuration forall devices exchanging scheduled streams on the network. SM 206 may bemirrored on peripheral device 200 to coordinate its internalconfiguration with the system (network) configuration flow. Peripheraldevice 200 may be informed of the different states of the networkconfiguration via SM 206. Once network configuration is completed,peripheral device 200 may be requested to start the scheduled datatransfer by setting the state of SM 206 to “Running” (308). The variousstates of SM 206 may be defined as follows, according to someembodiments:

Initialization:

-   -   The initialization state (302) allows the application executing        on the device (e.g. executing on device 100 shown in FIG. 1) to        initialize its peripherals (e.g. peripherals 112 . . . 116 shown        in FIG. 1, one of which may be an improved network interface        peripheral device such as the one shown in FIG. 2, for example,        one embodiment of which is shown operating as peripheral device        112 in FIG. 1). The network interface peripheral device may        transition into this state when it is powered on, and may remain        in this state until the application requests it to transition        out of the Init state into the Configuration state. While in the        Init state, the network interface peripheral device may perform        the following (e.g. based on input from the application):        -   1. Create the PDBs and configure the DHF with the respective            memory addresses of the data source peripherals and data            sink peripherals. Data source peripherals may be defined as            the peer-peripherals (e.g. peripherals 114 . . . 116 shown            in FIG. 1) that produce the data which is included in the            payload of the scheduled streams that are transmitted by the            network interface peripheral. Data sink peripherals may be            defined as the peer-peripherals which consume the data in            the payload of the scheduled streams received by the network            interface peripheral.        -   2. Create the NDBs based on the number of network streams            and their payload sizes.

Configuration:

-   -   After the application has finished initialization, it may        transition into the Configuration state (304) automatically or        upon request by a centralized system configuration entity. In        the Configuration state, the network interface peripheral device        is ready to receive stream transmission(s) and reception        schedule information from the system configuration (via the        application on the device). The schedule may contain the        transmission times (e.g. period and offset within the period)        for each stream transmitted on the network, and the latest        arrival time of a stream received from the network.

Ready:

-   -   The device may transition into the Ready state (306) after the        schedule information has been successfully downloaded to it. In        the Ready state, the network transmission/reception layer on the        network interface peripheral device may be configured with the        transmission and reception schedule. The SF may be configured        with the transmit and receive events that inform the DHF when to        perform its operations.

Running:

-   -   The device may transition into the Running state (308) when all        the devices exchanging scheduled streams have successfully        transitioned to the Ready state (306) and the network is also        appropriately configured. In the Running state, scheduled data        transmission by the network transmission/reception layer may be        activated. The SF creates the transmit events and receive events        required for the DHF to perform its operations.

Exemplary Operation

FIG. 4 shows an exemplary system diagram of a system configuration withan improved network interface peripheral device, according to someembodiments. As shown in FIG. 4, a Centralized System Configuration 408,Network Schedule Generator 406 and Application Schedule Generator 410may be external entities used to configure the system which is composedof multiple devices (100, 412, 414) connected to a network 118. TheNetwork Schedule Generator 406 and the Application Schedule Generator410 may be used to generate/implement timed-functions in system 400.Centralized System Configuration 408 may provide a configurationinterface to the network for the device 100 and may operate as a linkbetween the user 450, the Network Schedule Generator 406, theApplication Schedule Generator 410 and the application executing on thedevice 100. A device 100, in this context, may be as shown in FIG. 1,and may include a CPU subsystem, a network interface peripheral device(A) and other peer-peripherals ((B) . . . (C)), similar to the device100 shown in FIG. 1. The application executing on the device 100 mayinclude logic/instructions/functions executing on the CPU, andlogic/instructions/functions executing on one or more peripherals. Theapplication may generate (create) the links between the peer-to-peerdata sources and data sinks with the network interface peripherals, andthe data sources and sinks between the CPU and the peripherals(including the network interface peripheral device).

FIG. 6 shows an exemplary flow chart illustrating configuration of anetwork interface peripheral device that manages scheduled data transferover the network. In other words, FIG. 6 illustrates configuration ofthe network interface peripheral device to send and receive data streamsfrom peer-peripherals according to specified time schedule(s). When thenetwork interface peripheral device (e.g. peripheral device (A) in FIG.4 or peripheral device 112 in FIG. 1) is powered on, it starts in theInitialization State (610). It should be noted that the various statesare referenced with respect to the SM 206, as detailed in FIG. 3. Whilein the Initialization state (610), the application executing on the maindevice (e.g. on main device 100) may receive a request from the systemconfiguration entity (e.g. entity 408 shown in FIG. 4) to transition tothe Configuration state (608). Upon receiving that request, theapplication executing on the main device may perform internalapplication initialization which may include configuring the datasources and data sinks between the CPU and the peripherals, and betweenthe various peripherals—i.e. peer-to-peer peripheral configuration(612). The internal application initialization may also includeconfiguring the network interface peripheral device with the PDBs tostore the data sets from the peer peripherals (614). The application maythen configure the DHF with the source and sink information of the PDBs,e.g. with link information between PDBs and data sets on the peerperipherals (616). The network interface peripheral device may thencreate the mapping between the PDBs and NDBs, e.g. based on the numberof network streams and payload size (618).

The application may then publish the requirements for systemconfiguration, e.g. the number of network streams it intends totransmit/receive, and may also publish the application timingconstraints (e.g. fastest period it can run the application, minimumpreparation time before performing any function, etc.) for the systemconfiguration to read (620). At this point the application (running) onthe main device is ready to receive configuration information from thesystem configuration (622). After this internal initialization theapplication may transition the main device into the Configuration state(624).

The Network Schedule Generator 406 (referring to FIG. 4) may operate toschedule the network streams between devices connected to each otherover the network (e.g. devices 100, 412 and 414 in FIG. 4). TheApplication Schedule Generator may compute the schedule oftimed-functions on the master device. The system configuration entityreads the published stream and application timing information (626). Itmay obtain the user requirements—e.g. period of streams, stream linkinformation, latency requirements etc. —(628), and provide these userrequirements along with the stream and application timing constraints tothe Application Schedule Generator (630). The Application ScheduleGenerator (e.g. the Application Schedule Generator 410 in FIG. 4) maycompute the stream relationships (e.g. does one stream need to finishbefore the second one starts, etc.) and possible start times for thestreams and the maximum latency acceptable to meet the applicationtiming constrains. This information is then relayed to the networkschedule generator (632) which computes the schedule for the streamswithin the network. It returns the start time of streams fortransmission and the expected arrival time of the streams for receptionto the system configuration entity. The system configuration distributesthis information along with application timing information to all thedevices it is configuring (634). Then it requests all the devices totransition to the Ready state (636).

Receipt of a state transition request by the (main) device to transitionto the Ready state is indicative of the application executing/running onthe (main) device having received the stream schedule and applicationtiming information. Accordingly, the main device provides the streamschedule to the network interface peripheral device (638). The networkinterface peripheral device then configures the network transmission andreception layer with this schedule and links it to the NDBs (640). Thenetwork interface peripheral device also configures the SF with timinginformation indicative of (or indicating) when to create the DH transmitevents and DH receive events (642). These events instruct the DH to movethe data between the PDBs and the other peripherals, and between thePDBs and the NDBs.

The DH transmit event may be computed based on a specified time duration(e.g. a maximum time duration, which may be considered worst case) itmay take to fetch the data from the peripheral device into the PDBs, andcopying the data from the PDBs into the NDB. This ensures that the datais ready in the NDB before the deadline of the transmission time. Theremay be a one-to-one mapping between a DH transmit event and atransmitted stream. Upon reception, the SF may signal the DH when thedata in an NDB has arrived by creating a DH receive event. The DH thendistributes the data from the NBD to one or more PDBs and sends themfrom the PDBs to the peer peripherals. There may be a one-to-one mappingbetween a DH reception event and a received stream. This is illustratedin the timing diagram 500 shown in FIG. 5. As seen in timing diagram500, upon a DH start event being initiated (512), the data is fetchedinto the PDBs (504), then multiplexed into the NDB (506), subsequent towhich the data stream transmission may begin (508). The data streamtransmission period may be of a specified duration (516), during whichanother DH transmit event may be initiated (514) such that a new datastream transmission may begin (510) upon completion of the present datastream transmission (516).

Referring again to FIG. 6, after the network interface has beenconfigured with the schedule information, the device successfullytransitions to the Ready state (644). When all devices configured by thesystem configuration have successfully transitioned to the Ready state(646), the system configuration may request all the devices totransition to the Running state (648). At this point the configurationis complete.

In the Running state, data streams may be transmitted at specifiedpoints in time (e.g. every period, at a specified offset) by the networkinterface peripheral device, and the DH events may be initiated for datastream transmission and reception as configured, at specified points intime (e.g. every period), to move the data between the stream payloadand the peer peripherals.

Various Embodiments

In some embodiments, the DHF may be implemented on a peripheral deviceother than the network interface peripheral device. Furthermore, the DHFmay be configured with future time events for creating the receiveevents rather than explicit signals from the SF upon arrival of datainto the NDB. In such cases the DH receive event may be computed bytaking into account a specified latency (e.g. maximum latency, orarrival time) of the data stream provided by the centralized systemconfiguration entity. In some embodiments, the DHF may be disaggregatedinto two separate components (or sub-functions). A first components mayfacilitate the data transfer into the PDBs from the NBD and from the NBDto the PBDs, and a second component may facilitate transmission of thedata between the peripherals and the PDBs. In some embodiments, theperipheral devices may be configured with future time events (assumingthe peripheral devices have synchronized clocks with respect to eachother) to push and pull data from PBDs on the network interfaceperipheral device instead of the DHF on the network interface peripheraldevice performing the pushing and pulling of data.

Exemplary Systems

Various embodiments disclosed herein may be involved with performingtest and/or measurement functions; controlling and/or modelinginstrumentation or industrial automation hardware; modeling andsimulation functions, e.g., modeling or simulating a device or productbeing developed or tested, etc. Exemplary test applications where thegraphical program may be used include hardware-in-the-loop testing andrapid control prototyping, among others. However, it is noted thatvarious embodiments may be used for a plethora of applications and isnot limited to the above applications. In other words, applicationsdiscussed in the present description are exemplary only, and thedisclosed embodiments may be used in any of various types of systems.Thus, embodiments of the system and method disclosed herein may beconfigured to be used in any of various types of applications, includingthe control of other types of devices such as multimedia devices, videodevices, audio devices, telephony devices, Internet devices, etc., aswell as general purpose software applications such as word processing,spreadsheets, network control, network monitoring, financialapplications, games, etc.

The following describes various exemplary systems that may implementembodiments of the present techniques.

FIG. 7A illustrates an exemplary instrumentation control system 700which may implement various embodiments disclosed herein. The system 700comprises a host computer 781 which couples to one or more instruments.The host computer 781 may comprise a CPU, a display screen, memory, andone or more input devices such as a mouse or keyboard as shown. Thecomputer 781 may operate with the one or more instruments to analyze,measure or control a unit under test (UUT) or process 750, e.g., viaexecution of software 704.

The one or more instruments may include a GPIB instrument 711 andassociated GPIB interface card 722, a data acquisition board 714inserted into or otherwise coupled with chassis 724 with associatedsignal conditioning circuitry 726, a VXI instrument 716, a PXIinstrument 718, a video device or camera 732 and associated imageacquisition (or machine vision) card 734, a motion control device 736and associated motion control interface card 738, and/or one or morecomputer based instrument cards 742, among other types of devices. Thecomputer system may couple to and operate with one or more of theseinstruments. The instruments may be coupled to the unit under test (UUT)or process 750, or may be coupled to receive field signals, typicallygenerated by transducers. The system 700 may be used in a dataacquisition and control application, in a test and measurementapplication, an image processing or machine vision application, aprocess control application, a man-machine interface application, asimulation application, or a hardware-in-the-loop validationapplication, among others.

FIG. 7B illustrates an exemplary industrial automation system 800 whichmay implement embodiments disclosed herein. The industrial automationsystem 800 is similar to the instrumentation or test and measurementsystem 700 shown in FIG. 7A. Elements which are similar or identical toelements in FIG. 7A have the same reference numerals for convenience.The system 800 may comprise a computer 781 which couples to one or moredevices or instruments. The computer 781 may comprise a CPU, a displayscreen, memory, and one or more input devices such as a mouse orkeyboard as shown. The computer 781 may operate with the one or moredevices to perform an automation function with respect to a process ordevice 751, such as HMI (Human Machine Interface), SCADA (SupervisoryControl and Data Acquisition), portable or distributed data acquisition,process control, advanced analysis, or other control, among others,e.g., via execution of software 704.

The one or more devices may include a data acquisition board 714inserted into or otherwise coupled with chassis 724 with associatedsignal conditioning circuitry 726, a PXI instrument 718, a video device732 and associated image acquisition card 734, a motion control device736 and associated motion control interface card 738, a fieldbus device770 and associated fieldbus interface card 772, a PLC (ProgrammableLogic Controller) 776, a serial instrument 782 and associated serialinterface card 784, or a distributed data acquisition system, such asFieldpoint system 785, available from National Instruments Corporation,among other types of devices.

FIG. 8A is a high level block diagram of an exemplary system which mayexecute or utilize graphical programs. FIG. 8A illustrates a generalhigh-level block diagram of a generic control and/or simulation systemwhich comprises a controller 792 and a plant 794. The controller 792represents a control system/algorithm the user may be trying to develop.The plant 794 represents the system the user may be trying to control.For example, if the user is designing an ECU for a car, the controller792 is the ECU and the plant 794 is the car's engine (and possibly othercomponents such as transmission, brakes, and so on.) As shown, a usermay create a graphical program that specifies or implements thefunctionality of one or both of the controller 792 and the plant 794.For example, a control engineer may use a modeling and simulation toolto create a model (graphical program) of the plant 794 and/or to createthe algorithm (graphical program) for the controller 792.

FIG. 8B illustrates an exemplary system which may perform control and/orsimulation functions. As shown, the controller 792 may be implemented bya computer system 781 or other device (e.g., including a processor andmemory medium and/or including a programmable hardware element) thatexecutes or implements a graphical program. In a similar manner, theplant 794 may be implemented by a computer system or other device 744(e.g., including a processor and memory medium and/or including aprogrammable hardware element) that executes or implements a graphicalprogram, or may be implemented in or as a real physical system, e.g., acar engine.

In some embodiments, one or more graphical programs may be created whichare used in performing rapid control prototyping. Rapid ControlPrototyping (RCP) generally refers to the process by which a userdevelops a control algorithm and quickly executes that algorithm on atarget controller connected to a real system. The user may develop thecontrol algorithm using a graphical program, and the graphical programmay execute on the controller 792, e.g., on a computer system or otherdevice. The computer system 781 may be a platform that supports realtime execution, e.g., a device including a processor that executes areal time operating system (RTOS), or a device including a programmablehardware element.

In some embodiments, one or more graphical programs may be created whichare used in performing Hardware in the Loop (HIL) simulation. Hardwarein the Loop (HIL) refers to the execution of the plant model 794 in realtime to test operation of a real controller 792. For example, once thecontroller 792 has been designed, it may be expensive and complicated toactually test the controller 792 thoroughly in a real plant, e.g., areal car. Thus, the plant model (implemented by a graphical program) isexecuted in real time to make the real controller 792 “believe” oroperate as if it is connected to a real plant, e.g., a real engine.

In the embodiments of FIGS. 7A, 7B, and 8B above, one or more of thevarious devices may couple to each other over a network, such as theInternet. In one embodiment, the user operates to select a target devicefrom a plurality of possible target devices for programming orconfiguration using program, e.g., a graphical program. Thus the usermay create a (possibly graphical) program on a computer and use(execute) the program on that computer or deploy the program to a targetdevice (for remote execution on the target device) that is remotelylocated from the computer and coupled to the computer through a network.

Graphical software programs which perform data acquisition, analysisand/or presentation, e.g., for measurement, instrumentation control,industrial automation, modeling, or simulation, such as in theapplications shown in FIGS. 7A and 7B, may be referred to as virtualinstruments. It should be noted that in various embodiments, one or moreof the software (or firmware) program or components used to implementthe present techniques, e.g., timed functions, schedule generator(s),etc., may be implemented in any kind of programs desired, includingtextual and/or graphical programs, e.g., graphical data flow programs.

FIG. 10—Computer System Block Diagram

FIG. 9 is a block diagram 900 representing one embodiment of thecomputer system 781 in FIGS. 7A, 7B, and 8B. It is noted that any typeof computer system configuration or architecture can be used as desired,and FIG. 9 illustrates a representative PC embodiment. It is also notedthat the computer system may be a general purpose computer system, acomputer implemented on a card installed in a chassis, or other types ofembodiments. Elements of a computer not necessary to understand thepresent description have been omitted for simplicity.

The computer may include at least one central processing unit or CPU(processor) 760 which is coupled to a processor or host bus 762. The CPU760 may be any of various types, including an x86 processor, e.g., aPentium class, a PowerPC processor, an Intel® Core™ i7 class, a CPU fromthe SPARC family of RISC processors, as well as others. A memory medium,typically comprising RAM and referred to as main memory, 766 is coupledto the host bus 762 by means of memory controller 764. The main memory766 may store one or more programs implementing the techniques disclosedherein. The main memory may also store operating system software, aswell as other software for operation of the computer system.

The host bus 762 may be coupled to an expansion or input/output bus 770by means of a bus controller 768 or bus bridge logic. The expansion bus770 may be the PCI (Peripheral Component Interconnect) expansion bus,although other bus types can be used. The expansion bus 770 includesslots for various devices such as described above. The computer 781further comprises a video display subsystem 780 and hard drive 782coupled to the expansion bus 770. The computer 781 may also comprise aGPIB card 722 coupled to a GPIB bus 712, and/or an MXI device 786coupled to a VXI chassis 716.

As shown, a device 790 may also be connected to the computer. The device790 may include a processor and memory which may execute a real timeoperating system. The device 790 may also or instead comprise aprogrammable hardware element. The computer system may be configured todeploy a (possibly graphical) program to the device 790 for execution ofthe program on the device 790. In some embodiments, the deployed programmay be a graphical program, and may take the form of graphical programinstructions or data structures that directly represents the graphicalprogram. Alternatively, the deployed graphical program may take the formof text code (e.g., C code) generated from the graphical program. Asanother example, the deployed graphical program may take the form ofcompiled code generated from either the graphical program or from textcode that in turn was generated from the graphical program.Alternatively, the program may be a textual program.

The following describes exemplary creation of a graphical program,according to one embodiment. First, a graphical user interface or frontpanel for the graphical program may be created, e.g., in response touser input. The graphical user interface may be created in any ofvarious ways, e.g., depending on the graphical programming developmentenvironment used. A block diagram for the graphical program may becreated. The block diagram may be created in or using any graphicalprogramming development environment, such as LabVIEW, Simulink, VEE, oranother graphical programming development environment. The block diagrammay be created in response to direct user input, e.g., the user maycreate the block diagram by placing or “dragging and dropping” icons ornodes on the display and interconnecting the nodes in a desired fashion.Alternatively, the block diagram may be programmatically created from aprogram specification. The plurality of nodes in the block diagram maybe interconnected to visually indicate functionality of the graphicalprogram. The block diagram may have one or more of data flow, controlflow, and/or execution flow representations.

It is noted that the graphical user interface and the block diagram maybe created separately or together, in various orders, or in aninterleaved manner. In one embodiment, the user interface elements inthe graphical user interface or front panel may be specified or created,and terminals corresponding to the user interface elements may appear inthe block diagram in response. For example, when the user places userinterface elements in the graphical user interface or front panel,corresponding terminals may appear in the block diagram as nodes thatmay be connected to other nodes in the block diagram, e.g., to provideinput to and/or display output from other nodes in the block diagram. Inanother embodiment, the user interface elements may be created inresponse to the block diagram. For example, the user may create theblock diagram, wherein the block diagram includes terminal icons ornodes that indicate respective user interface elements. The graphicaluser interface or front panel may then be automatically (or manually)created based on the terminal icons or nodes in the block diagram. Asanother example, the graphical user interface elements may be comprisedin the diagram.

Other techniques for creating graphical programs may be used as desired,e.g., programmatically, or a combination of manual and programmatictechniques.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A peripheral device comprising: a network interface configured tofacilitate communication of the peripheral device with a network; aninterconnect interface configured to facilitate communication of theperipheral device with a processor subsystem; a first set of buffersconfigured to hold peripherals data associated with peer peripheraldevices coupled to the processor subsystem; a second set of buffersconfigured to hold payload data of scheduled data streams transmittedover the network; and a data handler configured to perform at least oneof the following: generate the payload data from the peripherals dataand store the payload data in the second set of buffers for transmissionover the network, according to one or more timed events; or generate theperipherals data from the payload data and store the peripherals data inthe second set of buffers for transmission to the peer peripheraldevices, according to the one or more timed events.
 2. The peripheraldevice of claim 1, further comprising a scheduler configured to createthe one or more timed events.
 3. The peripheral device of claim 1,wherein the one or more timed events comprise at least one of thefollowing: one or more transmit events, wherein each respective transmitevent of the one or more transmit events instructs the data handler tofetch corresponding transmit data comprised in the peripherals data,generate at least a portion of the payload data from the correspondingtransmit data, and store the at least a portion of the payload data inthe second set of buffers for transmission over the network; or one ormore receive events, wherein each respective receive event of the one ormore receive events instructs the data handler to fetch correspondingreceive data comprised in the payload data, generate at least a portionof the peripherals data from the corresponding receive data, and storethe at least a portion of the peripherals data in the first set ofbuffers for transmission to the peer peripheral devices.
 4. Theperipheral device of claim 1, wherein the peripherals data comprises oneor more data sets, wherein the first set of buffers comprises onerespective buffer per peer peripheral device per data set.
 5. Theperipheral device of claim 1, wherein the peripherals data comprisesmultiple data sets corresponding to a single peer peripheral device. 6.The peripheral device of claim 1, wherein the second set of bufferscomprises one respective buffer per scheduled data stream of thescheduled data streams.
 7. The peripheral device of claim 1, wherein thescheduled data streams comprise: transmit data streams transmitted bythe peripheral device; and receive data streams received by theperipheral device.
 8. The peripheral device of claim 1, wherein the datahandler is further configured to multiplex peripherals data frommultiple buffers comprised in the first set of buffers into a singlebuffer comprised in the second set of buffers.
 9. The peripheral deviceof claim 1, wherein the data handler is further configured to distributepayload data from a single buffer comprised in the second set of buffersinto multiple buffers comprised in the first set of buffers.
 10. Theperipheral device of claim 1, wherein the data handler is furtherconfigured to use the interconnect interface to perform at least one ofthe following: transmit data to the peer peripheral devices from thefirst set of buffers; or receive data from the peer peripheral devicesinto the first set of buffers.
 11. The peripheral device of claim 1,further comprising a state machine configured to coordinate internalinitialization and set up of the peripheral device with a centralizedsystem configuration flow.
 12. The peripheral device of claim 1, whereinthe state machine is controlled by a centralized system configurationentity disposed outside of the peripheral device.
 13. A host devicecomprising: a processor subsystem configured to execute one or moreapplications; one or more peer peripheral devices coupled to theprocessor subsystem; and a network interface peripheral device (NIPD)comprising: a network interface configured to facilitate communicationof the NIPD with a network; an interconnect interface configured tofacilitate communication of the NIPD with the processor subsystem; afirst set of buffers configured to hold peripherals data associated withthe one or more peer peripheral devices; a second set of buffersconfigured to hold payload data of scheduled data streams transmittedover the network; and a data handler configured to perform at least oneof the following: generate the payload data from the peripherals dataand store the payload data in the second set of buffers for transmissionover the network, according to one or more timed events; or generate theperipherals data from the payload data and store the peripherals data inthe second set of buffers for transmission to the one or more peerperipheral devices, according to the one or more timed events.
 14. Thehost device of claim 13, wherein the one or more timed events compriseat least one of the following: one or more transmit events, wherein eachrespective transmit event of the one or more transmit events instructsthe data handler to fetch corresponding transmit data comprised in theperipherals data, generate at least a portion of the payload data fromthe corresponding transmit data, and store the at least a portion of thepayload data in the second set of buffers for transmission over thenetwork; or one or more receive events, wherein each respective receiveevent of the one or more receive events instructs the data handler tofetch corresponding receive data comprised in the payload data, generateat least a portion of the peripherals data from the correspondingreceive data, and store the at least a portion of the peripherals datain the first set of buffers for transmission to the one or more peerperipheral devices.
 15. The host device of claim 13, wherein theperipherals data comprises one or more data sets, wherein the first setof buffers comprises one respective buffer per peer peripheral device ofthe one or more peer peripheral devices per data set, and wherein thesecond set of buffers comprises one respective buffer per scheduled datastream of the scheduled data streams.
 16. The host device of claim 13,wherein the peripherals data comprises multiple data sets correspondingto a single peer peripheral device of the one or more peer peripheraldevices, and wherein the scheduled data streams comprise: transmit datastreams transmitted by the NIPD; and receive data streams received bythe NIPD.
 17. The host device of claim 1, wherein the data handler isfurther configured to perform one or more of the following: multiplexperipherals data from multiple buffers comprised in the first set ofbuffers into a single buffer comprised in the second set of buffers;distribute payload data from a single buffer comprised in the second setof buffers into multiple buffers comprised in the first set of buffers;transmit data over the interconnect interface to the one or more peerperipheral devices from the first set of buffers; or receive data overthe interconnect interface from the one or more peer peripheral devicesinto the first set of buffers.
 18. A networked system for scheduled datatransfer on a network, the networked system comprising: a centralizedsystem configuration entity configured to interface with the network andconfigure one or more components of the networked system; and a mainhost device comprising: a processor subsystem configured to execute oneor more applications; one or more peer peripheral devices coupled to theprocessor subsystem; and a network interface peripheral device (NIPD)comprising: a network interface configured to facilitate communicationof the NIPD with the network; an interconnect interface configured tofacilitate communication of the NIPD with the processor subsystem; afirst set of buffers configured to hold peripherals data associated withthe one or more peer peripheral devices; a second set of buffersconfigured to hold payload data of scheduled data streams transmittedover the network; and a data handler configured to perform at least oneof the following: generate the payload data from the peripherals dataand store the payload data in the second set of buffers for transmissionover the network, according to one or more timed events; or generate theperipherals data from the payload data and store the peripherals data inthe second set of buffers for transmission to the one or more peerperipheral devices, according to the one or more timed events.
 19. Thenetworked system of claim 18, wherein the NIPD further comprises a statemachine configured to coordinate internal initialization and set up ofthe NIPD, wherein the state machine is controlled by the centralizedsystem configuration entity.
 20. The networked system of claim 18,further comprising one or more additional host devices configured tointerface with the network.